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Abstract 

WSDL is an XML format for describing network services as a set of endpoints operating on 
messages containing either document-oriented or procedure-oriented information. The 
operations and messages are described abstractly, and then bound to a concrete network 
protocol and message format to define an endpoint. Related concrete endpoints are combined 
into abstract endpoints (services). WSDL is extensible to allow description of endpoints and their 
messages regardless of what message formats or network protocols are used to communicate, 
however, the only bindings described in this document describe how to use WSDL in 
conjunction with SOAP 1.1. HTTP GET/POST, and MIME. 

Status 

This document is a submission to the Worl d Wide We b Consortium (see Submission Request . 
W3C Staff Comment ) as a suggestion for describing services for the W3C XML Activity on XML 
Protoc ols. For a full list of all acknowledged Submissions, please see A cknowled ged 
Submissions t o W3C . 

This draft represents the current thinking with regard to descriptions of services within Ariba, 
IBM and Microsoft. It consolidates concepts found in NASSL, SCL, and SDL (earlier proposals 
in this space). 
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This document is a NOTE made available by the W3C for discussion only. Publication of this 
Note by W3C indicates no endorsement by W3C or the W3C Team, or any W3C Members. 
W3C has had no editorial control over the preparation of this Note. This document is a work in 
progress and may be updated, replaced, or rendered obsolete by other documents at any time. 

A list of current W3C technical documents can be found at the Technical Reports page. 
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1. Introduction . 

As communications protocols and message formats are standardized in the web community, it 
becomes increasingly possible and important to be able to describe the communications in 
some structured way. WSDL addresses this need by defining an XML grammar for describing 
network services as collections of communication endpoints capable of exchanging messages. 
WSDL service definitions provide documentation for distributed systems and serve as a recipe 
for automating the details involved in applications communication. 

A WSDL document defines services as collections of network endpoints, or ports. In WSDL, 
the abstract definition of endpoints and messages is separated from their concrete network 
deployment or data format bindings. This allows the reuse of abstract definitions: messages, 
which are abstract descriptions of the data being exchanged, and port types which are abstract 
collections of operations. The concrete protocol and data format specifications for a particular 
port type constitutes a reusable binding. A port is defined by associating a network address 
with a reusable binding, and a collection of ports define a service. Hence, a WSDL document 
uses the following elements in the definition of network services: 

• Types- a container for data type definitions using some type system (such as XSD). 

• Message- an abstract, typed definition of the data being communicated. 

• Operation- an abstract description of an action supported by the service. 

• Port Type-an abstract set of operations supported by one or more endpoints. 
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• Binding- a concrete protocol and data fomiat specification for a particular port type. 

. Port- a single endpoint defined as a combination of a binding and a network address. 

• Service- a collection of related endpoints. 

These elements are described in detail in Section 2. It is important to observe that WSDL does 
not introduce a new type definition language. WSDL recognizes the need for rich type systems 
for describing message formats, and supports the XML Schemas specification (XSD) [H] as its 
canonical type system. However, since it is unreasonable to expect a single type system 
grammar to be used to describe all message formats present and future, WSDL allows using 
other type definition languages via extensibility. 

In addition. WSDL defines a common binding mechanism. This is used to attach a specific 
protocol or data format or structure to an abstract message, operation, or endpoint. It allows the 
reuse of abstract definitions. 

In addition to the core service definition framework, this specification introduces specific binding 
extensions for the following protocols and message formats: 

• SOAP 1.1 (see^ection_3) 

• HTTP GET / POST ( see Section 4) 

• MIME (see Section 5) 

Although defined within this document, the above language extensions are layered on top of the 
core service definition framework . Nothing precludes the use of other binding extensions with 
WSDL. 

1 .2 WSDL Document Example 

The following example shows the WSDL definition of a simple service providing stock quotes. 
The service supports a single operation called GetLastTradePrice, which is deployed using the 
SOAP 1.1 protocol over HTTP. The request takes a ticker symbol of type string, and returns the 
price as a float. A detailed description of the elements used in this definition can be found in 
Section 2 (core language) and Section 3 (SOAP binding). 

This example uses a fixed XML format instead of the SOAP encoding (for an example using the 
SOAP encoding, see Example 4 ). 

Example 1 SOAP 1.1 Request/Response via HTTP 

<?xinl version="1.0"?> 
<definitions name="StockQuote" 

targetNamespace="http : / /example . com/stockquote . wsdl " 

xmlns : tns="http : //example . com/stockquote . wsdl" 
xmlns : xsdl="http: //example . com/stockquote . xsd" 
xmlns: soap="http: //schemas. xmlsoap.org/wsdl/soap/" 
xmlns="http: //schemas. xmlsoap.org/wsdl/"> 
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<types> 

<schema targetNamespace="http : //example . com/stockquote . xsd" 
xnilns="http: //www. w3. org/2000/ 10/XMLSchema"> 
<element name="TradePriceRequest"> 
<complexType> 
<all> 

<element name="tickerSyinbol" type="string"/> 
</all> 
</complexType> 
</element> 

<element name="TradePrice"> 

<complexType> 
<all> 

<elenient nanie="price" type="f loat "/> 
</all> 
</coinplexType> 
</element> 
</schema> 
</types> 

<message nanie="GetLastTradePriceInput "> 

<part name="body" element="xsdl:TradePriceRequest"/> 
</inessage> 

<message name="GetLastTradePriceOutput "> 

<part naine="body" eleinent="xsdl : TradePrice"/> 
</niessage> 

<portType name="StockQuotePortType"> 

<operation naine="GetLastTradePrice"> 

<input message="tns : GetLastTradePricelnput "/> 
<output message="tns :GetLastTradePriceOutput"/> 
</operation> 
</portType> 

<binding name="StockQuoteSoapBinding" type="tns : StockQuotePortType"> 

<soap: binding style="document" transport="http: //schemas . xmlsoap . org/soap/ht 
<operation name="GetLastTradePrice"> 

<soap: operation soapAction="http: //example . coin/GetLastTradePrice"/> 
<input> 

<soap:body use="literal"/> 
</input> 
<output> 

<soap:body use="literal"/> 
</output> 
</operation> 
</binding> 

<service name="StockQuoteService"> 

<documentation>My first service</documentation> 

<port name="StockQuotePort" binding="tns : StockQuoteBinding"> 

<soap: address location="http: //example . com/stockquote" /> 
</port> 

</service> 
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</definitions> 



1 .2 Notational Conventions 



1 The keywords "MUST'. "MUST NOT'. "REQUIRED". "SHALL". "SHALL NOT". "SHOULD". 
"SHOULD NOT', "RECOMMENDED". "MAY", and "OPTIONAL" In this document are to be 
interpreted as described in RFC-2119 [2]. 

2. The following namespace prefixes are used throughout this document: 



prefix namespace URI 



wsdl http://schemas.xmlsoap.org/wsdl/ 



soap http://schemas.xmlsoap.org/wsdl/soap/ 



http http://schemas.xmlsoap.org/wsdl/http/ 



mime http://schemas.xmlsoap.org/Wsdl/mime/ 



soapenc htt p://schemas.xmlsoap.ora/soap/encodina/ 



soapenv http;//sclMDas^mlsoap,oig/sQa^ 



XSI 



xsd 



http://Www.w3.ora/200Q/10/XMLSchema- 
instance 



http;//www. w3.prg/2000/1 0/XM LSchema 



definition 

WSDL namespace 
for WSDL 
framework. 

WSDL namespace 
for WSDL SOAP 
binding. 

WSDL namespace 
for WSDL HTTP 
GET & POST 
binding. 

WSDL namespace 
for WSDL MIME 
binding. 

Encoding 
namespace as 
defined by SOAP 
1.1 [8]. 

Envelope 
namespace as 
defined by SOAP 
1.1 [8]. 

Instance 
namespace as 
defined by XSD 
[-10]. 

Schema 
namespace as 
defined by XSD 

mi 
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The "this 



tns 



(various) 



namespace" (tns) 
prefix is used as a 
convention to refer 
to the current 



document. 



(other) (various) 



All other 

namespace prefixes 
are samples only. In 
particular, URIs 
starting with 
"http://example.com" 
represent some 
application- 
dependent or 
context-dependent 
URI HJ. 



3. This specification uses an informal syntax to describe the XML grammar of a WSDL 
document: 

• The syntax appears as an XML instance, but the values indicate the data types instead of 
values. 

• Characters are appended to elements and attributes as follows: "?" (0 or 1), "*" (0 or 
more), "+" (1 or more). 

• Elements names ending in (such as <element.../> or <element...>) indicate that 
elements/attributes irrelevant to the context are being omitted. 

• Grammar in bold has not been introduced earlier in the document, or is of particular 
interest in an example. 

• <- extensibility element -> is a placeholder for elements from some "other" namespace 
(like ##other in XSD). 

• The XML namespace prefixes (defined above) are used to indicate the namespace of the 
element being defined. 

• Examples starting with <?xml contain enough information to conform to this specification; 
others examples are fragments and require additional infomiation to be specified in order 
to conform. 

XSD schemas are provided as a formal definition of WSDL grammar (see section A4 ). 

2. Service Definition 

This section describes the core elements of the WSDL language. Binding extensions for SOAP, 
HTTP and MIME are included in Sections 3, 4 and 5. 

2.1 WSDL Document Structure 
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A WSDL document is simply a set of definitions. There is a definitions element at the root, 
and definitions Inside. The grammar is as follows: 

<wsdl: definitions name="nmtoken" ? targetNamespace="uri"?> 
<import namespace="uri" location="uri"/>* 
<wsdl: documentation ..../>? 

<wsdl:types> ? 

<wsdl : documentation .... />? 

<xsd: schema .... />* 

< — extensibility element — > * 
</wsdl:types> 

<wsdl: message name="nmtoken"> * 
<wsdl : documentation .... />? 

<part name="nmtoken" element="qname"? type="qname"?/> * 
</wsdl :message> 

<wsdl : portType name="nmtoken">* 
<wsdl : documentation .... />? 
<wsdl : operation name="nmtoken">* 
<wsdl : documentation .... /> ? 
<wsdl: input name="nmtoken"? message="qname">? 

<wsdl : documentation .... /> ? 
</wsdl : input> 

<wsdl: output name="nmtoken"? message="qname">? 

<wsdl: documentation .... /> ? 
</wsdl : output> 

<wsdl: fault name="nmtoken" message="qname"> * 

<wsdl: documentation .... /> ? 
</wsdl:fault> 
</wsdl : operation> 
</wsdl :portType> 

<wsdl: binding name="nmtoken" type="qname">* 
<wsdl : documentation .... />? 
< — extensibility element — > * 
<wsdl : operation name="nmtoken">* 
<wsdl : documentation .... /> ? 
< — extensibility element — > * 
<wsdl:input> ? 

<wsdl: documentation .... /> ? 
< — extensibility element — > 
</wsdl : input> 
<wsdl:output> ? 

<wsdl: documentation .... /> ? 
< — extensibility element — > * 
</wsdl : output> 

<wsdl: fault name="nmtoken"> * 

<wsdl : documentation .... /> ? 

< — extensibility element — > * 
</wsdl: fault> 
</wsdl : operation> 
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</wsdl : binding> 

<wscll: service name="nmtoken"> * 
<wsdl : documentation .... />? 
<wsdl:port name="nmtoken" binding="qname"> * 

<wsdl : documentation .... /> ? 

< — extensibility element — > 
</wsdl :port> 

< — extensibility element — > 
</wsdl : service> 

< — extensibility element — > * 
</wsdl : def initions> 

Services are defined using six major elements: 

• types, which provides data type definitions used to describe the messages exchanged. 

• message, which represents an abstract definition of the data being transmitted. A 
message consists of logical parts, each of which is associated with a definition within 
some type system. 

• portType, which is a set of abstract operations. Each operation refers to an input 
message and output messages. 

• binding, which specifies concrete protocol and data format specifications for the 
operations and messages defined by a particular portType. 

• port, which specifies an address for a binding, thus defining a single communication 
endpoint. 

• service, which is used to aggregate a set of related ports. . 

These elements will be described in detail in Sections 2.2 to 2.7. In the rest of this section we 
describe the rules introduced by WSDL for naming documents, referencing document 
definitions, using language extensions and adding contextual documentation. 

2.1.1 Document Naming and Linking 

WSDL documents can be assigned an optional name attribute of type NCNAME that serves as 
a lightweight form of documentation. Optionally, a targetNamespace attribute of type URI may 
be specified. The URI MUST NOT be a relative URI. 

WSDL allows associating a namespace with a document location using an import statement: 

<def initions .... > 

<iiBport namespace="uri" location="uri"/> * 

</def initions> 

A reference to a WSDL definition is made using a QName . The following types of definitions 
contained in a WSDL document may be referenced: 

• WSDL definitions: service, port, message, bindings, and portType 
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• Other definitions: if additional definitions are added via extensibility, they SHOULD use 
QName linking. 

Each WSDL definition type listed above has its own name scope (i.e. port names and message 
names never conflict). Names within a name scope MUST be unique within the WSDL 
document. 

The resolution of QNames in WSDL is similar to the resolution of QNames described by the 
-XML Schemas specification [H]. 

2.1.2 Authoring Style 

The use of the import element allows the separation of the different elements of a service 
definition into independent documents, which can then be imported as needed. This technique 
helps writing clearer service definitions, by separating the definitions according to their level of 
abstraction. It also maximizes the ability to reuse service definitions of all kinds. As a result, 
WSDL documents structured in this way are easier to use and maintain. Example 2 below 
shows how to use this authoring style to define the service presented in Example 1. Here we 
separate the definitions in three documents: data type definitions, abstract definitions, and 
specific service bindings. The use of this mechanism is of course not limited to the definitions 
explicitly presented in the example, which uses only language elements defined in this 
specification. Other types of definitions based on additional language extensions can be 
encoded and reused in a similar fashion. 

Example 2. Alternative authoring style for the service in Example 1. 
http://example.com/stockquote/stockquote.xsd 

<?xml version="1.0"?> 

<schema targetNamespace="http: //example . com/stockquote/schemas" 
xmlns="http://www.w3.org/2000/10/XMLSchema"> 

<element name="TradePriceRequest "> 
<complexType> 
<all> 

<element name="tickerSymbol" type="string"/> 
</all> 
</complexType> 
</element> 

<element name="TradePrice"> 
<coinplexType> 
<all> 

<element nanie="price" type="f loat"/> 

</all> 
</complexType> 
</element> 
</schema> 

http://example.com/stockquote/stockquote.wsdl 
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<?xml version="1.0"?> 
<definitions name="StockQuote" 



targetNamespace="http: //example. com/stockquote/definitions" 

xmlns : tns="http : //example . com/stockquote/def initions" 
xmlns : xsdl="http: //example . com/stockquote/schemas" 
xmlns : soap="http : //schemas . xmlsoap . org/wsdl/soap/" 
xmlns="http: //schemas . xmlsoap. org/wsdl/"> 

<import ncunespace="http: //example. com/stockquote/schemas" 

locations "http : / /example . com/s tockquote/stockquote . xsd"/> 

<message name="GetLastTradePriceInput "> 

<part name="body" element="xsdl : TradePriceRequest "/> 
</message> 

<message name="GetLastTradePriceOutput"> 

<part name="body" element="xsdl :TradePrice"/> 
</message> 

<portType name="StockQuotePortType"> 

<operation name="GetLastTradePrice"> 

<input message="tns :GetLastTradePriceInput"/> 
<output message="tns :GetLastTradePriceOutput"/> 
</operation> 
</portType> 
</def initions> 



http://example.com/stockquote/stockquoteservice.wsdl 

<?xml version="1.0"?> 
<definitions name="StockQuote" 

targetNamespace="http: //example . com/s tockquote/ service" 

xmlns : tns="http : //example . com/s tockquote/service" 
xmlns ; soap="http: //schemas . xmlsoap . org/wsdl/soap/" 
xmlns :defs="http: //example . com/stockquote/def initions" 
xmlns="http : //schemas . xmlsoap . org/wsdl/ "> 



<import namespace="http : //example . com/stockquote/def initions" 

locations "http : //example . com/s tockquote/stockquote . wsdl"/> 

<binding name="StockQuoteSoapBinding" type="defs: StockQuotePortType"> 

<soap : binding styie="docuraent " transport="http : //schemas . xmlsoap . org/soap/ht 
<operation name="GetLastTradePrice"> 

<soap: operation soapAction="http: //example. com/Get Las tTradePr ice" /> 
<input> 

<soap:body use="literal"/> 
</input> 
<output> 

<soap:body use="literal"/> 
</output> 
</operation> 
</binding> 
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<service name="StockQuoteService"> 

<docunientation>My first service</documentation> 

<port name="StockQuotePort" binding="tns : StockQuoteBinding"> 

<soap: address location="http: //example. com/stockquote"/> 
</port> 
</service> 
</def initions> 

2.1.3 Language Extensibility and Binding 

In WSDL the term binding refers to the process associating protocol or data format information 
with an abstract entity like a message, operation, or portType. WSDL allows elements 
representing a specific technology (referred to here as extensibility elements) under various 
elements defined by WSDL. These points of extensibility are typically used to specify binding 
infomnation for a particular protocol or message format, but are not limited to such use. 
Extensibility elements MUST use an XML namespace different from that of WSDL. The specific 
locations in the document where extensibility elements can appear are described in detail in 
section A3. 

Extensibility elements are commonly used to specify some technology specific binding. To 
distinguish whether the semantic of the technology specific binding is required for 
communication or optional, extensibility elements MAY place a wsdhrequlred attribute of type 
boolean on the element. The default value for required is false. The required attribute is defined 
in the namespace "http://schemas.xmlsoap.org/wsdir. 

Extensibility elements allow innovation in the area of network and message protocols without 
having to revise the base WSDL specification. WSDL recommends that specifications defining 
such protocols also define any necessary WSDL extensions used to describe those protocols or 
formats. 

See Sections 3, 4, and 5 for examples of extensibility elements defined as part of the base 
WSDL specification. 

2.1.4 Documentation 

WSDL uses the optional wsdhdocument element as a container for human readable 
documentation. The content of the element is arbitrary text and elements ("mixed" in XSD). The 
documentation element is allowed inside any WSDL language element. 

2.2 Types 

The types element encloses data type definitions that are relevant for the exchanged 
messages. For maximum interoperability and platform neutrality, WSDL prefers the use of XSD 
as the canonical type system, and treats it as the intrinsic type system. 

<def initions .... > 
<types> 

<xsd: schema .... />* 
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</types> 
</definitions> 

The XSD type system can be used to define the types in a message regardless of whether or 
not the resulting wire format is actually XML, or whether the resulting XSD schema validates the 
particular wire format. This is especially interesting if there will be multiple bindings for the same 
message, or if there is only one binding but that binding type does not already have a type 
system in widespread use. In these cases, the recommended approach for encoding abstract 
types using XSD is as follows: 

• Use element form (not attribute). 

• Don't include attributes or elements that are peculiar to the wire encoding (e.g. have 
nothing to do with the abstract content of the message). Some examples are soap:root, 
soap:encodingStyle, xmi:id, xmi:name. 

• Array types should extend the Array type defined in the SOAP v1 .1 encoding schema 
(http:// schemas.xmlsoap. org /soap/encodin g/) (regardless of whether the resulting form 
actually uses the encoding specified in Section 5 of the SOAP v1.1 document). Use the 
name ArrayOfXXX for array types (where XXX is the type of the items in the array). The 
type of the items in the array and the array dimensions are specified by using a default 
value for the soapenc:arrayType attribute. At the time of this writing, the XSD specification 
does not have a mechanism for specifying the default value of an attribute which contains 
a QName value. To overcome this limitation, WSDL introduces the arrayType attribute 
(from namespace http://schemas.xmlsoap.org/wsdl/) which has the semantic of providing 
the default value. If XSD is revised to support this functionality, the revised mechanism 
SHOULD be used in favor of the arrayType attribute defined by WSDL. 

• Use the xsd:anyType type to represent a field/parameter which can have any type. 

However, since it is unreasonable to expect a single type system grammar can be used to 
describe all abstract types present and future, WSDL allows type systems to be added via 
extensibility elements. An extensibility element may appear under the types element to identify 
the type definition system being used and to provide an XML container element for the type 
definitions. The role of this element can be compared to that of the schema element of the XML 
Schema language. 

<definitions .... > 
<types> 

< — type-system extensibility element — > * 
</types> 
</def initions> 

2.3 Messages 

Messages consist of one or more logical parts. Each part is associated with a type from some 
type system using a message-typing attribute. The set of message-typing attributes is 
extensible. WSDL defines several such message-typing attributes for use with XSD: 

• element. Refers to an XSD element using a QName. 



httprZ/www. vv3.org/TR/wsdl 



6/28/2004 



Web Service Definition Language (WSDL) 



Page 14 of 48 



• type. Refers to an XSD simpleType or complexType using a QName. 

Other message-typing attributes may be defined as long as they use a namespace different 
from that of WSDL. Binding extensibility elements may also use message-typing attributes. 

The syntax for defining a message is as follows. The message-typing attributes (which may vary 
depending on the type system used) are shown in bold. 

<def initions .... > 

<message name="nmtoken"> * 

<part name="nmtoken" element="qname"? type="qname"?/> * 

</message> 
</def initions> 

The message name attribute provides a unique name among all messages defined within the 
enclosing WSDL document. 

The part name attribute provides a unique name among all the parts of the enclosing message. 
2.3.1 Message Parts ^ 

Parts are a flexible mechanism for describing the logical abstract content of a message. A 
binding may reference the name of a part in order to specify binding-specific information about 
the part. For example, if defining a message for use with RPC, a part MAY represent a 
parameter in the message. However, the bindings must be inspected in order to determine the 
actual meaning of the part. 

Multiple part elements are used if the message has multiple logical units. For example, the 
following message consists of a Purchase Order and an Invoice. 

<definitions .... > 
<types> 

<schema .... > 

<element nan\e="PO" type="tns : POType"/> 
<complexType name="POType"> 
<all> 

<element name^"ici" type="string/> 
<element name="name" type="string"/> 
<element name=" items "> 
<complexType> 
<all> 

<eleinent name="item" type="tns : Item" minOccurs="0" ma 
</all> 
</complexType> 
</element> 
</all> 
</complexType> 

<complexType name="Item"> 
<all> 
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<element name="quantity" type="int"/> 
<eleinent name="product" type="string"/> 
</all> 
</complexType> 

<element name="Invoice" type="tns : InvoiceType"/> 
<complexType naine="InvoiceType"> 
<all> 

<element name=="id" type="string"/> 
</all> 
</complexType> 
</schema> 
</types> 

<message name="PO"> 

<part name="po" elemGnt="tns : P0"/> 

<part name="invoice" element="tns : Invoice"/> 

</message> 
</def initions> 

However, if the message contents are sufficiently complex, then an alternative syntax may be 
used to specify the composite structure of the message using the type system directly. In this 
usage, only one part may be specified. In the following example, the body is either a purchase 
order, or a set of invoices. 

<definitions .... > 
<types> 

<schema .... > 

<coinplexType name="POType"> 
<all> 

<element name="id" type="string/> 
<element name="name" type="string"/> 
<element name=" items "> 
<coniplexType> 
<all> 

<element name="item" type="tns : Item" minOccurs="0" ma 
</all> 
</complexType> 
</element> 
</all> 
</complexType> 

<complexType name="Item"> 
<all> 

<element name="quantity" type="int"/> 
<element name="product " type="string"/> 
</all> 
</complexType> 

<complexType name="InvoiceType"> 
<all> 

<element name="id" type="string"/> 
</all> 
</complexType> 

<complexType name="Co]aposite"> 
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<choice> 

<element ncuae="PO" minOccurs="l" maxOccurs="l" type="tns : POType"/ 
<element namG=" Invoice" minOccurs="0" maxOccurs="tinbounded" type= 
</choice> 
< / complexType> 

</schema> 
</types> 

<message name="PO"> 

<part name="composite" typ6="tns: Compos ite"/> 

</message> 
</def initions> 

2.3.2 Abstract vs. Concrete Messages 

Message definitions are always considered to be an abstract definition of the message content. 
A message binding describes how the abstract content is mapped into a concrete format. 
However, in some cases, the abstract definition may match the concrete representation very 
closely or exactly for one or more bindings, so those binding(s) will supply little or no mapping 
information. However, another binding of the same message definition may require extensive 
mapping information. For this reason, it is not until the binding is inspected that one can 
determine "how abstract" the message really is. 

2.4 Port Types 

A port type is a named set of abstract operations and the abstract messages involved. 

<wsdl : definitions .... > 

<wsdl : portType name= "ma token "> 

<wsdl : operation name=s"nm token" .... /> * 
</ wsdl : por tType> 

</wsdl :def initions> 

The port type name attribute provides a unique name among all port types defined within in the 
enclosing WSDL document. 

An operation is named via the name attribute. 

WSDL has four transmission primitives that an endpoint can support: 

• One-way. The endpoint receives a message. 

• Request-response. The endpoint receives a message, and sends a correlated message. 

• Solicit-response. The endpoint sends a message, and receives a correlated message. 

• Notification. The endpoint sends a message. 

WSDL refers to these primitives as operations. Although request/response or solicit/response 
can be modeled abstractly using two one-way messages, it is useful to model these as primitive 
operation types because: 
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• They are very common. 

• The sequence can be correlated without having to introduce more complex flow 

information. 

• Some endpoints can only receive messages if they are the result of a synchronous 
request response. 

• A simple flow can algorithmically be derived from these primitives at the point when flow 
definition is desired. 

Although request/response or solicit/response are logically correlated in the WSDL document, a 
given binding describes the concrete correlation Information. For example, the request and 
response messages may be exchanged as part of one or two actual network communications. 

Although the base WSDL structure supports bindings for these four transmission primitives, 
WSDL only defines bindings for the One-way and Request-response primitives. It is expected 
that specifications that define the protocols for Soliclt-response or Notification would also include 
WSDL binding extensions that allow use of these primitives. 

Operations refer to the messages Involved using the message attribute of type QName. This 
attribute follows the rules defined by WSDL for linking (see sectio n 2.1.2 ). 

2.4.1 One-way Operation 

The grammar for a one-way operation is: 

<wsdl: definitions > <wsdl : portType .... > * 

<wsdl : operation name- "nm token "> 

<wsdl: input naiBe="niBtoken"? messa9e="qn2UBe"/> 
</wsdl : operation> 

</wsdl : portType > 
</wsdl :def initions> 

The input element specifies the abstract message format for the one-way operation. 

2.4.2 Request-response Operation 

The grammar for a request-response operation is: 

<wsdl : definitions .... > 

<wsdl : portType .... > * 

<wsdl : operation naine="nmtoken" parameterOrder="nmtokens"> 
<wsdl: input n2uiie="nni token"? message="qname"/> 
<wsdl: output naiiie="nmtoken"? iiiessage="qncuae"/> 
<wsdl: fault name="nm token" message="<^aiiie"/>* 
</wsdl : operation> 
</wsdl: portType > 
</wsdl :def initions> 

The input and output elements specify the abstract message format for the request and 
response, respectively. The optional fault elements specify the abstract message fomriat for any 
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error messages that may be output as the result of the operation (beyond those specific to the 
protocol). 

Note that a request-response operation is an abstract notion; a particular binding must be 
consulted to determine how the messages are actually sent: within a single communication 
(such as a HTTP request/response), or as two independent communications (such as two HTTP 
requests). 

2.4.3 Solicit-response Operation 

The grammar for a solicit-response operation is: 

<wsdi: definitions .... > 

<wsdl rportType .... > * 

<wsdl: operation name="nmtoken" parameterOrder="nmtokens"> 
<wsdl: output name="nm token"? message="qname"/> 
<wsdl: input name="nm token"? message="qname"/> 
<wsdl: fault name="nmtoken" message="qname"/>* 
</wsdl : operation> 
</wsdl rportType > 
</wsdl : def initions> 

The output and input elements specify the abstract message format for the solicited request and 
response, respectively. The optional fault elements specify the abstract message format for any 
error messages that may be output as the result of the operation (beyond those specific to the 
protocol). 

Note that a solicit-response operation is an abstract notion; a particular binding must be 
consulted to determine how the messages are actually sent: within a single communication 
(such as a HTTP request/response), or as two independent communications (such as two HTTP 
requests). 

2.4.4 Notification Operation 

The grammar for a notification operation is: 

<wsdl :def initions .... > 

<wsdl:portType .... > * 

<wsdl : operation name="njii token "> 

<wsdl: output naxae="niQ token"? message="qname"/> 
</wsdl : opera tion> 
</wsdl iportType > 
</wsdl : def initions> 

The output element specifies the abstract message format for the notification operation. 

2.4.5 Names of Elements within an Operation 

The name attribute of the input and output elements provides a unique name among all input 
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and output elements within the enclosing port type. 

In order to avoid having to name each input and output element w/ithin an operation, WSDL 
provides some default values based on the operation name. If the name attribute is not specified 
on a one-way or notification message, it defaults to the name of the operation. If the name 
attribute is not specified on the input or output messages of a request-response or solicit- 
response operation, the name defaults to the name of the operation with "RequestT'Solicit" or 
"Response" appended, respectively. 

Each fault element must be named to allow a binding to specify the concrete format of the fault 
message. The name of the fault element is unique within the set of ^ults defined for the 
operation. 

2.4.6 Parameter Order within an Operation 

Operations do not specify whether they are to be used with RPC-like bindings or not. However, 
when using an operation with an RPC-binding, it is useful to be able to capture the original RPC 
function signature. For this reason, a request-response or solicit-response operation MAY 
specify a list of parameter names via the parameterOrder attribute (of type nmtokens). The 
value of the attribute is a list of message part names separated by a single space. The value of 
the parameterOrder attribute MUST follow the following rules: 

• The part narne order reflects the order of the parameters in the RPC signature 

• The return value part is not present in the list 

• If a part name appears in both the input and output message, it is an in/out parameter 

• If a part name appears in only the input message, it is an in parameter 

• If a part name appears in only the output message, it Is an out parameter 

Note that this information serves as a "hint" and may safely be ignored by those not concerned 
with RPC signatures. Also, it is not required to be present, even if the operation is to be used 
with an RPC-like binding. 

2.5 Bindings 

A binding defines message format and protocol details for operations and messages defined by 
a particular portType. There may be any number of bindings for a given portType. The grammar 
for a binding is as follows: 

<wsdl : definitions .... > 

<wscll : binding ncuiie="nmtoken" type="cpxame"> * 
< — extensibility element (1) — > * 
<wsdl : operation ncUBe="nmtoken"> * 

< — extensibility element (2) — > * 
<wsdl: input names "nm token"? > ? 

< — extensibility element (3) — > 
</wsdl : input> 

<wsdl: output name="nm token"? > ? 

< — extensibility element (4) — > * 
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</wsdl : output> 

<wsdl: fault name="nmtoken"> * 

< — extensibility element (5) — > * 
</wsdl : f ault> 
</wsdl : opera tion> 
</wscll : binding> 
</wscll:ciefinitions> 

The name attribute provides a unique name among all bindings defined within in the enclosing 
WSDL document. 

A binding references the portType that it binds using the type attribute. This QName value 
follows the linking rules defined by WSDL (see section 2.1.2). 

Binding extensibility elements are used to specify the concrete grammar for the input (3), output 
(4), and fault messages (5). Per-operation binding information (2) as well as per-binding 
information (1) may also be specified. 

An operation element within a binding specifies binding information for the operation with the 
same name within the binding's portType. Since operation names are not required to be unique 
(for example, in the case of overloading of method names), the name attribute in the operation 
binding element might not be enough to uniquely identify an operation. In that case, the correct 
operation should be identified by providing the name attributes of the corresponding wsdhinput 
and wsdhoutput elements. 

A binding MUST specify exactly one protocol. 

A binding MUST NOT specify address information. 

2.6 Ports 

A port defines an individual endpoint by specifying a single address for a binding. 

<wsdl : definitions .... > 
<wsdl: service .... > * 

<wsdl:port naiae="niii token" binding="qname"> * 

< — extensibility element (1) — > 
</wsdl : port> 
</wsdl : service> 
</wsdl : def initions> 

The name attribute provides a unique name among all ports defined within in the enclosing 
WSDL document. 

The binding attribute (of type QName) refers to the binding using the linking rules defined by 
WSDL (see Section 2.1.2 ). 

Binding extensibility elements (1) are used to specify the address information for the port. 
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A port MUST NOT specify more than one address. 

A port MUST NOT specify any binding infomfiation other than address infomiatlon. 
2.7 Services 

A service groups a set of related ports together: 

<wsdl : definitions .... > 

<wsdl: service nanie="nintoken"> * 
<wsdl : port .... />* 

</wsdl : service> 
</wsdl : def initions> 

The name attribute provides a unique name among ail services defined within in the enclosing 
WSDL document. 

Ports within a service have the following relationship: 

• None of the ports communicate with each other (e.g. the output of one port is not the input 
of another). 

• If a service has several ports that share a port type, but employ different bindings or 
addresses, the ports are alternatives. Each port provides semantically equivalent behavior 
(within the transport and message format limitations imposed by each binding). This allows 
a consumer of a WSDL document to choose particular port(s) to communicate with based 
on some criteria (protocol, distance, etc.). 

• By examining it's ports, we can determine a service's port types. This allows a consumer 
of a WSDL document to determine if it wishes to communicate to a particular service 
based whether or not it supports several port types. This is useful if there is some implied 
relationship between the operations of the port types, and that the entire set of port types 
must be present in order to accomplish a particular task. 

3. SOAP Binding 

WSDL includes a binding for SOAP 1.1 endpoints, which supports the specification of the 
following protocol specific information: 

• An indication that a binding is bound to the SOAP 1.1 protocol 

• A way of specifying an address for a SOAP endpoint. 

• The URI for the SOAPAction HTTP header for the HTTP binding of SOAP 

• A list of definitions for Headers that are transmitted as part of the SOAP Envelope 

This binding grammar it is not an exhaustive specification since the set of SOAP bindings is 
evolving. Nothing precludes additional SOAP bindings to be derived from portions of this 
grammar. For example: 
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• SOAP bindings that do not employ a URI addressing scheme may substitute another 
addressing scheme by replacing the soap:address element defined in section^S. 

• SOAP bindings that do not require a SOAPAction omit the soapAction attribute defined in 
sectio n 3.4 . 



3.1 SOAP Examples 

In the following example, a SubscribeToQuotes SOAP 1.1 one-way message is sent to a 
StockQuote service via a SMTP binding. The request takes a ticker symbol of type string, and 
includes a header defining the subscription URI. 



Example 3. SOAP binding of one-way operation over SIWTP using a SOAP Header 

<?xml version="1.0"?> 
<definitions name="StockQuote" 

targetNamespace="http: //example . com/stockquote . wsdl" 

xmlns : tns="http : //example . com/stockquote . wsdl " 

xmlns : xsdl="http : //example . com/stockquote . xsd" 

xmlns : soap="http : //schemas . xmlsoap . org/wsdl/soap/ " 

xmlns="http : / /schemas . xmlsoap . org/wsdl/ "> 

<message name="SubscribeToQuotes"> 

<part name="body" element="xsdl : SubscribeToQuotes"/> 

<part name="subscribeheader" element="xsdl : StabscriptionHeader"/> 

</message> 

<portType name="StockQuotePortType"> 

<operation name="SubscribeToQuotes"> 

<input message="tns : SubscribeToQuotes"/> 

</operation> 
</portType> 

<binding name="StockQuot€Soap" type="tns : StockQuotePortType"> 

<soap : binding style=" document" transport="http : //example - coin/smtp"/> 
<operation name="SubscribeToQuotes"> 

<input message="tns : SubscribeToQuotes "> 

<soap:body parts="body" use="literal"/> 

<soap: header message="tns : SiabscribeToQuotes" part="s\abscribeheader" u 

</input> 
</operation> 
</binding> 

<service name="StockQuoteService"> 

<port name="StockQuotePort" bindings" tns : StockQuoteSoap"> 
<soap : address location="mailto : subscribes example . com"/> 

</port> 
</service> 



<types> 

<schema targetNamespace="http: //example . com/stockquote . xsd" 
xmlns= "ht tp : / /www . w3 . org /2 000 / 10 /XMLSchema " > 
<element name="SubscribeToQuotes"> 
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<coinplexType> 
<all> 

<element name="tickerSymbol" type="string"/> 
</all> 
</complexType> 
</element> 

<element name="SubscriptionHeader" type="uriRef erence"/> 
</scheina> 
</types> 
</def initions> 

This example describes that a GetTradePrice SOAP 1.1 request may be sent to a StockQuote 
service via the SOAP 1.1 HTTP binding. The request takes a ticker symbol of type string, a time 
of type timelnstant, and returns the price as a float in the SOAP response. 

Example 4. SOAP binding of request-response RPC operation over HTTP 

<?xml version="1.0"?> 
<definitions name="StockQuote" 

t argetNamespace="ht tp : / /example . com/s tockquote . wsdl " 

xmlns : tns="http : //example . com/stockquote . wsdl" 

xmlns:xsd="http: //www. w3.org/2000/10/XMLSchema" 

xmlns : xsdl="http : / /example . com/stockquote , xsd" 

xmlns : soap="http: //schemas . xmlsoap . org/wsdl/soap/" 

xmlns="http: //schemas . xmlsoap. org/wsdl/"> 

<message name="GetTradePriceInput "> 

<part name="tickerSymbol" element="xsd: string"/> 

<part name="time" element="xsd: timeInstant"/> . 
</message> 

<message name="GetTradePriceOutput "> 

<part name="result" type="xsd: float "/> 
</message> 

<portType name="StockQuotePortType"> 
<operation name="GetTradePrice"> 

<input message="tns :GetTradePriceInput"/> 
<output message="tns:GetTradePriceOutput"/> 
</operation> 
</portType> 

<binding name="StockQuoteSoapBinding" type="tns : StockQuotePortType"> 

<soap:binding style="rpc" transport="http: //schemas . xmlsoap. org/ soap/http"/> 
<operation name="GetTradePrice"> 

<soap : operation soapAction="http : //example . com/GetTradePrice*'/> 
<input> 

<8oap:body use="encoded" namespace="http: //example . com/stockquote" 

encodings tyle="http : //schemas . xmlsoap . org/ soap/encoding/ "/ 

</input> 

<output> 

<soap :body use="encoded" namespace="http : //exeuaple . com/stockquote" 

encodingStyle="http: //schemas . xmlsoap. org/ soap/encoding/"/ 

</output> 
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</operation» 
</bincling> 

<service name="StockQuoteService"> 

<documentation>My first service</documentation> 

<port name="StockQuotePort " binding="tns : StockQuoteBinding"> 

<soap:address location="http: //example. com/stockquote"/> 
</port> 
</service> 
</def initions> 

This example describes that a GetTradePrices SOAP 1.1 request may be sent to a StockQuote 
service via the SOAP 1.1 HTTP binding. The request takes a stock quote symbol string, an 
application defined TimePeriod structure containing a start and end time and returns an array of 
stock prices recorded by the service within that period of time, as well as the frequency at which 
they were recorded as the SOAP response. The RPC signature that corresponds to this service 
has in parameters tickerSymbol and timePeriod followed by the output parameter frequency, 
and returns an array of floats. 

Example 5. SOAP binding of request-response RPC operation over HTTP 

<?xml version="1.0"?> 
<definitions name="StockQuote" 

targetNamespace="http : / /example . com/stockquote . wsdl " 

xmlns : tns="http : //example . com/stockquote . wsdl" 

xmlns:xsd="http: //www. w3.org/2000/10/XMLSchema" 

xmlns :xsdl="http: //example. com/stockquote/schema" 

xmlns : soap="http : //schemas . xmlsoap . org/wsdl/soap/" 

xmlns : soapenc="http : //schemas . xmlsoap . org/soap/encoding/" 

xmlns="http: //schemas .xmlsoap. org/wsdl/"> 

<types> 

<schema targetNamespace="http: //example . com/stockquote/schema" 
xmlns="http: //www. w3 . org/2000/10/XMLSchema"> 
<complGxType name=" TimePeriod "> 
<all> 

<element nsuae="startTime" type="xsd: timGlnstant"/> 
<element name="endTime" type="xsd: timeInstant"/> 
</all> 
</coiiiplexType> 

<complexType name="ArrayOfFloat"> 
<complexContent> 

<rGstriction base="soapenc : Array "> 

<attribute ref="soapenc: array Type" wsdl : array Type="xsd: float [ ] 
</restriction> 
</complexContent> 
</complexType> 
</ schema > 
</types> 

<message name= "GetTradePrices Input "> 

<part name="tickerSymbol" element="xsd: string"/> 
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<part name="timePeriod" element="xsdl :TimePeriod"/> 
</message> 

<message name="GetTradePricesOutput"> 

<part name="result" type="xsdl :ArrayOf Float "/> 

<part name=" frequency" type="xsd: f loat"/> 
</message> 

<portType name="StockQuotePortType"> 

<operation name="GetLastTradePrice" parameterOrder^" ticker Symbol timePeriod 

<input message="tns :GetTradePricesInput"/> 
<output message="tns :GetTradePricesOutput"/> 
</operation> 
</portType> 

<binding name="StockQuoteSoapBinding" type="tns : StockQuotePortType"> 

<soap : binding style="rpc" transport="http : //schemas . xmlsoap . org/soap/http" /> 
<operation name="GetTradePrices"> 

<soap: operation soapAction="http: //example. com/GetTradePrices"/> 

<input> 

<soap:body use="encoded" namespace="http: //example . com/stockquote" 

encodingStyle="http : / /schemas . xmlsoap . org/soap/encoding/ " / 

</input> 
<output> 

<soap:body use="encoded" namespace="http: //example . com/stockquote" 

encodingStyle="http : //schemas . xmlsoap . org/soap/encoding/ " / 

</output> 
</operation» 
</binding> 

<service name="StockQuoteService"> 

<documentation>My first service</documentation> 

<port name="StockQuotePort" binding="tns : StockQuoteBinding"> 

<soap: address location="http: //example. com/stockquote" /> 
</port> 
</service> 
</def initions> 



3.2 How the SOAP Binding Extends WSDL 

The SOAP Binding extends WSDL with the following extension elements: 



<def initions .... > 
<binding . . , . > 

<soap:binding style="rpc| docxament" trcmsport="uri"> 
<operation .... > 

<soap : operation soapAction="uri"? style="rpc | document"?>? 
<input> 

<soap:body par ts="nm tokens"? use="literal | encoded" 

encodingStyle="uri-list"? ncunespace="uri"?> 
<soap: header message="qname" par t="nm token" use= " 11 teral | encoded" 
encodingStyle="uri-list"? namespace="uri"?>* 
<soap : headerf ault message="qnaiiie" par t="nm token" use= "li teral | encod 

encodingStyle="uri-list"? namespace="uri"?/>* 
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<soap : header> 

</input> 
<output> 

<soap:body parts="nmtokens"? use=" literal I encoded" 

encodings tyle="uri-list"? namespace= "ur i " ? > 
<soap: header niessage="qname" part="nmtoken" use="literal I encoded" 
encodings ty le= "uri-list"? namespace= " ur i " ? > * 
<soap:headerfault message="qnaiae" part="nmtoken" use="literal I encod 

encodingStyle="uri-list"? namespace="uri"?/>* 

<soap : header> 

</output> 
<fault>* 

<soap:fault name="nmtok6n" use="literal | encoded" 

encodingStyle="uri-list"? naiiiespace="uri"?> 

</fault> 
</operation> 
</binding> 

<port .... > 

<soap: address location="uri"/> 

</port> 
</cief initions> 

Each extension element of the SOAP binding is covered in subsequent sections. 

3.3 soapibinding 

The purpose of the SOAP binding element is to signify that the binding is bound to the SOAP 
protocol format: Envelope, Header and Body. This element makes no claims as to the encoding 
or format of the message (e.g. that it necessarily follows section 5 of the SOAP 1.1 
specification). 

The soap:binding element MUST be present when using the SOAP binding. 

<def initions .... > 
<binding .... > 

<soap : binding transport="uri"? style="rpc | doc\ament"?> 

</binding> 
</def initions> 

The value of the style attribute is the default for the style attribute for each contained operation. 
If the style attribute is omitted, it is assumed to be "document". See section 3.4 for more 
information on the semantics of style. 

The value of the required transport attribute indicates which transport of SOAP this binding 
corresponds to. The URI value http://schemas.xmlsoap.org/soap/http corresponds to the 
HTTP binding in the SOAP specification. Other URIs may be used here to indicate other 
transports (such as SMTP. FTP. etc.). 

3.4 soap:operation 
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The soapioperation element provides information for tlie operation as a whole. 

<definitions .... > 
<binding .... > 

<operation .... > 

<soap: operation soapAction="uri"? style="rpc| document"?>? 

</operation> 
</binding> 
</def initions> 

The style attribute indicates whether the operation is RPC-oriented (messages containing 
parameters and return values) or document-oriented (message containing document(s)). This 
information may be used to select an appropriate programming model. The value of this 
attribute also affects the way in which the Body of the SOAP message is constructed, as 
explained in Section 3.5 below. If the attribute is not specified, it defaults to the value specified 
in the soap:binding element. If the soap:binding element does not specify a style, it is assumed 
to be "document". 

The soapAction attribute specifies the value of the SOAPAction header for this operation. This 
URI value should be used directly as the value for the SOAPAction header; no attempt should 
be made to make a relative URI value absolute when making the request. For the HTTP 
protocol binding of SOAP, this is value required (it has no default value). For other SOAP 
protocol bindings, it MUST NOT be specified, and the soap:operation element MAY be omitted. 

3.5 soap:body 

The soap:body element specifies how the message parts appear inside the SOAP Body 
element. 

The parts of a message may either be abstract type definitions, or concrete schema definitions. 
If abstract definitions, the types are serialized according to some set of rules defined by an 
encoding style. Each encoding style is identified using a list of URIs, as in the SOAP 
specification. Since some encoding styles such as the SOAP Encoding 
(http://schemas.xmlsoap.org/soap/encoding/) allow variation in the message format for a given 
set of abstract types, it is up to the reader of the message to understand all the format 
variations: "reader makes right". To avoid having to support all variations, a message may be 
defined concretely and then indicate it's original encoding style (if any) as a hint. In this case, 
the writer of the message must conform exactly to the specified schema: "writer makes right". 

The soap:body binding element provides information on how to assemble the different message 
parts inside the Body element of the SOAP message. The soap: body element is used in both 
RPC-oriented and document-oriented messages, but the style of the enclosing operation has 
important effects on how the Body section is structured: 

• If the operation style is rpc each part is a parameter or a return value and appears inside a 
wrapper element within the body (following Section 7.1 of the SOAP specification). The 
wrapper element is named identically to the operation name and its namespace is the 
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value of the namespace attribute. Each message part (parameter) appears under the 
wrapper, represented by an accessor named identically to the corresponding parameter of 
the call. Parts are arranged in the same order as the parameters of the call. 
• If the operation style is document there are no additional wrappers, and the message parts 
appear directly under the SOAP Body element. 

The same mechanisms are used to define the content of the Body and parameter accessor 
elements. 

<def initions .... > 
<binding .... > 

<operation .... > 
<input> 

<soap : body par ts="nm tokens "? use="literal I encoded"? 

encodings tyle= "uri - li s t " ? namespace^ "ur i " ? > 

</input> 
<output> 

<soap:body partss"nm tokens"? uses"literal I encoded"? 

encodingStyle«"uri-list"? namespace="uri"?> 

</output> 
</operation> 

</binding> 
</def initions> 

The optional parts attribute of type nmtokens indicates which parts appear somewhere within 
the SOAP Body portion of the message (other parts of a message may appear in other portions 
of the message such as when SOAP is used in conjunction with the multipart/related MIME 
binding). If the parts attribute is omitted, then all parts defined by the message are assumed to 
be included in the SOAP Body portion. 

The required use attribute indicates whether the message parts are encoded using some 
encoding rules, or whether the parts define the concrete schema of the message. 

If use is encoded, then each message part references an abstract type using the type attribute. 
These abstract types are used to produce a concrete message by applying an encoding 
specified by the encodingStyle attribute. The part names, types and value of the namespace 
attribute are all inputs to the encoding, although the namespace attribute only applies to content 
not explicitly defined by the abstract types. If the referenced encoding style allows variations in 
it's format (such as the SOAP encoding does), then all variations MUST be supported ("reader 
makes right"). 

If use is literal, then each part references a concrete schema definition using either the element 
or type attribute. In the first case, the element referenced by the part will appear directly under 
the Body element (for document style bindings) or under an accessor element named after the 
message part (in rpc style). In the second, the type referenced by the part becomes the schema 
type of the enclosing element (Body for document style or part accessor element for rpc style). 
For an example that illustrates defining the contents of a composite Body using a type, see 
section 2._3.1 . The value of the encodingStyle attribute MAY be used when the use is literal to 
indicate that the concrete format was derived using a particular encoding (such as the SOAP 
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encoding), but that only the specified variation is supported ("writer makes right"). 

The value of the encodingStyle attribute is a list of URIs, each separated by a single space. 
The URI's represent encodings used within the message, in order from most restrictive to least 
restrictive (exactly like the encodingStyle attribute defined in the SOAP specification). 

3.6 soap:fauit 

The soap:fault element specifies the contents of the contents of the SOAP Fault Details 
element. It is patterned after the soap:body element (see section 3.5 ). 

<definitions .... > 
<binding .... > 

<operation .... > 
<fault>* 

<soap: fault name="nmtoken" us e= " li teral | encoded" 

encodings tyle= "ur i -list"? namespace= "uri " ? > 

</fault> 
</operation> 

</binding> 
</def initions> 

The name attribute relates the soap:fault to the wsdhfault defined for the operation. 

The fault message MUST have a single part. The use, encodingStyle and namespace 
attributes are all used in the same way as with soap:body (see section 3.5 ). only 
style="document" is assumed since faults do not contain parameters. 

3.7 soap:header and soap:headerfault 

The soap:header and soap:headerfault elements allows header to be defined that are 
transmitted inside the Header element of the SOAP Envelope. It is patterned after the 
soap:body element (see sect ion 3 .5). 

It is not necessary to exhaustively list all headers that appear in the SOAP Envelope using 
soap:header. For example, extensions (see section 2.1.3 ) to WSDL may imply specific headers 
should be added to the actual payload and it is not required to list those headers here. 

<def initions .... > 
<binding .... > 

<operation .... > 
<input> 

<soap: header niessage="qname" par t="nm token" use= "li teral | encoded" 
encodings ty 1 e="uri-list"? name space= "ur i " ? >* 
<soap: header fault message="qnaine" par t="nm token" use= "li teral | encoded 

encodingStyle="uri-list"? namespace="uri"?/>* 

<soap : header> 

</input> 
<output> 
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<soap: header mes8age="qname" parts'*nmtoken" use=*'literal I encoded" 
encodingStyle="uri-list"? namespace="uri"?>* 
<soap: header fault message="qname" par t="nin token" use="literal | encod 

encodingStyle="uri-list"? nauBespace="uri"?/>* 

<soap : header> 

</output> 
</operation> 
</binding> 
</definitions> 

"The use, encodingStyle and namespace attributes are all used in the same way as with 
soap:body (see section 3.5). only style="document" is assumed since headers do not contain 
parameters. 

Together, the message attribute (of type QName) and the part attribute (of type nmtoken) 
reference the message part that defines the header type. The schema referenced by the part 
MAY include definitions for the soap:actor and soap:mustUnderstand attributes if use-literal", 
but MUST NOT if use="encoded". The referenced message need not be the same as the 
message that defines the SOAP Body. 

The optional headerfault elements which appear inside soap:header and have the same syntax 
as soapiheader) allows specification of the header type(s) that are used to transmit error 
information pertaining to the header defined by the soap.header. The SOAP specification states 
that errors pertaining to headers must be returned in headers, and this mechanism allows 
specification of the format of such headers. 

3.8 soap:address 

The SOAP address binding is used to give a port an address (a URI). A port using the SOAP 
binding MUST specify exactly one address. The URI scheme specified for the address must 
correspond to the transport specified by the soap:binding. 

<cief initions .... > 
<port .... > 

<binding . . . . > 

<soap : address location="uri"/> 
</binding> 
</port> 
</def initions> 

4. HTTP GET & POST Binding 

WSDL includes a binding for HTTP 1 .1's GET and POST verbs in order to describe the 
interaction between a Web Browser and a web site. This allows applications other than Web 
Browsers to interact with the site. The following protocol specific information may be specified: 

• An indication that a binding uses HTTP GET or POST 

• An address for the port 
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• A relative address for each operation (relative to the base address defined by the port) 
4.1 HTTP GET/POST Examples 

The following example shows three ports that are bound differently for a given port type. 

If the values being passed are parti =1, part2=2, part3=3. the request format would be as follows 
for each port: 

portl: GET, URL="http : //example . com/ol/AlB2/3" 

port2 : GET, URL="http : //example . com/ol?pl=l&p2=2&p3=3 

port3: POST, URL="http: //example . com/ol", PAYLOAD="pl=l&p2=2&p3=3" 

For each port, the response is either a GIF or a JPEG image. 
Example 6. GET and FORM POST returning GIF or JPG 

<definitions .... > 

<message name="ml"> 

<part name="partl" type="xsci: string"/> 

<part name="part2" type="xsd: int"/> 

<part name="part3" type="xsd: string"/> 
</message> 

<message name="m2"> 

<part name="image" type="xsd:binary"/> 
</message> 

<portType name="ptl"> 

<operation name="ol"> 

<input message="tns:ml"/> 
<output message="tns :m2"/> 
</operation> 
</portType> 

<service naine="servicel"> 

<port name="portl" binding="tns :bl"> 

<http : address locat ion="http : / /example . com/ " /> 

</port> 

<port name="port2" binding="tns :b2"> 

<http: address locat ion="http: //example. com/" /> 
</port> 

<port name="port3" binding="tns : b3"> 

<http : address locat ion="http : / /example . com/ " /> 
</port> 
</service> 

<binding name="bl" type="ptl"> 
<http: binding verb=:"GET"/> 
<operation name=="ol"> 

<http : operation location="ol/A (parti) B (part2) / (part3) "/> 

<input> 
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<http : urlReplacement/> 

</input> 
<output> 

<mime : content type="image/gif "/> 
<mime : content type="image/ jpeg"/> 

</output> 
</operation> 
</binding> 

<binding name="b2" type="ptl"> 
<http: binding verb="GET"/> 
<operation naine="ol"> 

<http : operation location="ol "/> 
<input> 

<http : urlEncoded/> 
</input> 
<output> 

<mime: content type= " image /gif"/> 
<mime : content type="image/ jpeg"/> 

</output> 
</operation> 
</binding> 

<binding naine="b3" type="ptl"> 
<http : binding verb="POST"/> 
<operation name="ol"> 

<http : operation location="ol "/> 
<input> 

<miiiie : content type="application/x-www-f orm-urlencoded"/> 

</input> 
<output> 

<mime : content type="image/gif "/> 
<mime : content type= " image/ jpeg " /> 
</output> 
</operation> 
</binding> 
</def initions> 

4.2 How the HTTP GET/POST Binding Extends WSDL 

The HTTP GET/POST Binding extends WSDL with the following extension elements: 

<definitions .... > 
<binding .... > 

<http : binding verb="nmto]cen"/> 
<operation .... > 

<http : operation location="uri " /> 
<input .... > 

< — mime elements — > 
</input> 
<output .... > 

< — mime elements — > 
</output> 
</operation> 
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</binding> 

<port .... > 

<http: address locations "uri"/> 

</port> 
</def initions> 

These elements are covered in the subsequent sections. 

4.3 http:address 

The location attribute specifies the base URI for the port. The value of the attribute is combined 
with the values of the location attribute of the http:operation binding element. See section 4.5 for 
more details. 

4.4 http:binding 

The http:binding element indicates that this binding uses the HTTP protocol. 

<def initions .... > 
<binding .... > 

<http: binding verb= "nm token" /> 

</binding> 
</def initions> 

The value of the required verb attribute indicates the HTTP verb. Common values are GET or 
POST, but others may be used. Note that HTTP verbs are case sensitive. 

4.5 http:operation 

The location attribute specifies a relative URI for the operation. This URI is combined with the 
URI specified in the http:address element to form the full URI for the HTTP request. The URI 
value MUST be a relative URI. 

<def initions .... > 
<binding .... > 

<operation .... > 

<http: operation location="uri"/> 

</operation> 
</binding> 
</def initions> 

4.6 http:urlEncoded 

The urIEncoded element indicates that all the message parts are encoded into the HTTP 
request URI using the standard URI-encoding rules (name1=value&name2=value,..). The 
names of the parameters correspond to the names of the message parts. Each value 
contributed by the part is encoded using a name=value pair. This may be used with GET to 
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specify URL encoding, or with POST to specify a FORM-POST. For GET. the "?" character is 
automatically appended as necessary. 

<http : urlEncoded/> 

For more information on the rules for URI-encoding parameters, see [5], [6], and [7]. 
4.7 http:urlReplacement 

The http:urlReplacement element indicates that all the message parts are encoded into the 
HTTP request URI using a replacement algorithm: 

• The relative URI value of http: operation is searched for a set of search patterns. 

• The search occurs before the value of the http:operation is combined with the value of the 
location attribute from httpraddress. 

• There is one search pattern for each message part. The search pattern string is the name 
of the message part surrounded with parenthesis "(" and ")". 

• For each match, the value of the corresponding message part is substituted for the match 
at the location of the match. 

• Matches are performed before any values are replaced (replaced values do not trigger 
additional matches). 

Message parts MUST NOT have repeating values. 

<http : urlReplacement/> 

5. MIME Binding 

WSDL includes a way to bind abstract types to concrete messages in some MIME format. 
Bindings for the following MIME types are defined: 

• multipart/related 

• text/xml 

• application/x-www-form-urlencoded (the format used to submit a form in HTML) 

• Others (by specifying the MIME type string) 

The set of defined MIME types Is both large and evolving, so it is not a goal for WSDL to 
exhaustively define XML grammar for each MIME type. Nothing precludes additional grammar 
to be added to define additional MIME types as necessary. If a MIME type string is sufficient to 
describe the content, the mime element defined below can be used. 

5.11 MliVIE Binding example 

Example 7. Using multipart/related with SOAP 

This example describes that a GetCompanylnfo SOAP 1.1 request may be sent to a 
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StockQuote service via the SOAP 1.1 HTTP binding. The request takes a ticker symbol of type 
string. The response contains multiple parts encoded in the MIME fomiat multipart/related: a 
SOAP Envelope containing the current stock price as a float, zero or more marketing literature 
documents in HTML format, and an optional company logo in either GIF or JPEG format. 



<def initions .... > 



<types> 

<schema .... > 

<elenient name="GetCompanyInf o"> 
<complexType> 
<all> 

<element name="tickerSymbol " type="string"/> 
</all> 
</complexType> 
</eleinent> 

<element name="GetCompanyInfoResult"> 
<complexType> 
<all> 

<element name="result" type="f loat"/> 
</all> 
</coniplexType> 

</element> 

<complexType name="ArrayOf Binary"> 
<complexContent> 

<restriction base="soapenc: Array"> 

<attribute ref="soapenc:arrayType" wsdl :arrayType="xsci: binary [ 
</restriction> 
<complexContent> 
</complexType> 
</schenia> 
</types> 



<message name="ml"> 

<part name="body" eleinent="tns : GetCompanyInf o" /> 
</iiiessage> 

<message name="m2"> 

<part name="body" element="tns : GetCompanyInf oResult"/> 

<part name="docs" type="xsd: string"/> 

<part name="logo" type="tns lArrayOf Binary" /> 

</message> 



<portType name="ptl"> 

<operation naine= "GetCompanyInf o"> 
<input message="ml"/> 
<output message="m2"/> 
</operation> 
</portType> 



<binding name="bl" type="tns :ptl"> 

<operation name="GetCompanyInfo"> 

<soap : operation soapAction="http : //example . com/GetCompanyInf o"/> 
<input> 

<soap:body us6="literal"/> 
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</input> 
<output> 

<2iiime : mul tipartRelated> 
<mime : par t> 

<soap:body parts="body" use="literal"/> 
</miine : part> 
<mime : par t> 

<mijiie : content part="docs" type="text/htial"/> 
</mime : par t> 
<miiiie : par t> 

<miffle : content part="logo" type="image/gif "/> 
<mime : content part="logo" type="image/ jpeg"/> 
</mime : part> 
</mime : multipartRelated> 
</output> 
</operation> 
</binding> 

<service name="CompanyInfoService"> 

<port name="CompanyInf oPort"binding="tns :bl"> 

<soap : address location="http : //example . com/ companyinfo "/> 

</port> 
</service> 
</def initions> 

5.2 How the MIME Binding extends WSDL 

The MIME Binding extends WSDL with the following extension elements: 

<mime: content part="nmtoken"? type="string"?/> 

<mime : mult ipartRelated> 

<minie:part> * 

< — mime element — > 

</mime:part> 
</mime:multipartRelated> 

<mime : mimeXml par t = " nmt oken " ? / > 

They are used at the following locations in WSDL: 

<definitions .... > 
<binding .... > 

<operation .... > 
<input .... > 

< — mime elements — > 
</input> 
<output .... > 

< — mime elements — > 
</output> 
</operation> 
</binding> 
</def initions> 



http://\v'\v\v.\v3 .org/TR/wsdl 



6/28/2004 



Web Service Definition Language (WSDL) 



Page 37 of 48 



MIME elements appear under input and output to specify the MIME format. If multiple appear, 
they are considered to be alternatives. 

5.3 mime:content 

To avoid having to define a new element for every MIME format, the mimexontent element 
may be used if there is no additional information to convey about the fonnat other than its MIME 
type string. 

<mime : content part="nmtoken"? type="string"?/> 

The part attribute is used to specify the name of the message part. If the message has a single 
part, then the part attribute is optional. The type attribute contains the MIME type string. A type 
value has two portions, separated by a slash (/), either of which may be a wildcard (*). Not 
specifying the type attribute indicates that all MIME types are acceptable. 

If the return format is XML, but the schema is not known ahead of time, the generic mime 
element can be used indicating text/xml: 

<miine : content type="text/xml"/> 

A wildcard (*) can be used to specify a family of mime types, for example all text types. 

<mime : content type="text/*"/> 

The following two examples both specify all mime types: 

<niime : content type="*/*"/> 
<mime : content /> 

5.4 mime:multipartRelated 

The multipart/related MIME type aggregates an arbitrary set of MIME formatted parts into one 
message using the MIME type "multipart/related". The mlme:multipartRelatecl element 
describes the concrete format of such a message: 

<mime :multipartRelated> 

<mime:part> * 

< — mime element — > 

</mime:part> 
</mime : multipartRelated> 

The mlme:part element describes each part of a multipart/related message. MIME elements 
appear within mlme:part to specify the concrete MIME type for the part. If more than one MIME 
element appears inside a mime:part, they are alternatives. 

5.5 soap:body 
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When using the MIME binding with SOAP requests, it is legal to use the soap:body element as a 
MIME element. It indicates the content type Is "text/xml". and there is an enclosing SOAP 
Envelope. 

5.6 mime:mimeXml 

To specify XML payloads that are not SOAP compliant (do not have a SOAP Envelope), but do 
have a particular schema, the mime:mimeXml element may be used to specify that concrete 
schema. The part attribute refers to a message part defining the concrete schema of the root 
XML element. The part attribute MAY be omitted if the message has only a single part. The part 
references a concrete schema using the element attribute for simple parts or type attribute for 
composite parts (see section 2.3.1). 

<mime : mimeXml part="nnitoken"?/> 

6. References 

[2] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, 
Harvard University, March 1997 

[4] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource Identifiers (URI): Generic 
Syntax", RFC 2396 . MIT/LCS, U.C. Irvine, Xerox Corporation, August 1998. 

[5] htt p://www.w3.org/TR/html401/interact/forms.html - submit-format 

[6] htt p://www.w3.ora/TR/html401/appendix/notes.html - amoersands-in-uris 

[7] htt p://www.w3.orQ/TR/html401/interact/forms.html - h-17.13.4 

[8] Simple Object Access Protocol (SOAP) 1.1 "httpi/Zwysw^v^^^^ 
2.0000508r 

[10] W3C Working Draft " XML Schema Part 1 : Structures ". This is work in progress. 
[1 1] W3C Working Draft " XML Schema Part 2: Datatvoes ". This is work in progress. 

A 1. Notes on URIs 

This section does not directly contribute to the specification, but provide background that may 
be useful when implementing the specification. 

A 1.1 XML namespaces & schema locations 

It is a common misperception to equate the targetNamespace of an XML schema or the value of 
the xmlns attribute in XML instances with the location of the corresponding schema. Since 
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namespaces are in fact URIs, and URIs may be locations, and you may be abte to retrieve a 
schema from that location, It does not mean that is the only schema that is associated with that 
namespace. There can be multiple schemas associated with a particular namespace, and it is 
up to a processor of XML to determine which one to use in a particular processing context. The 
WSDL specification provides the processing context here via the <import> mechanism, which Is 
based on the XML schemas grammar for the similar concept. 

A 1.2 Relative URIs 

Throughout this document you see fully qualified URIs used In WSDL and XSD documents. The 
use of a fully qualified URI is simply to illustrate the referencing concepts. The use of relative 
URIs is completely allowed and is warranted in many cases. For information on processing 
relative URIs, see http://www.normos.orq/ietf/rfc/rfc2396.txt . 

A 1 .3 Generating URIs 

When working with WSDL, it is sometimes desirable to make up a URI for an entity, but not 
make the URI globally unique for all time and have it "mean" that version of the entity (schema, 
WSDL document, etc.). There is a particular URI base reserved for use for this type of behavior. 
. The base URI "http://tempuri.org/" can be used to construct a URI without any unique 
association to an entity. For example, two people or programs could choose to simultaneously 
use the URI "http://tempuri.org/myschema" for two completely different schemas, and as long as 
the scope of the use of the URIs does not intersect, then they are considered unique enough. 
This has the further benefit that the entity referred to by the URI can be versioned without 
having to generate a new URI, as long as it makes sense within the processing context. It Is not 
recommended that "http://tempuri.orgr be used as a base for stable, fixed entities. 

A 2. Wire format for WSDL examples 
A 2.1. Example 1 

SOAP Message Embedded in HTTP Request 

POST /StockQuote HTTP/1.1 
Host: www.stockquoteserver.com 
Content-Type: text/xml; charset="utf-8" 
Content-Length: nnnn 
SOAPAction: "Some-URI" 

<soapenv: Envelope xmlns : soapenv="http: //schemas .xmlsoap.org/soap/envelope/"> 
<soapenv : Body> 

<m:GetLastTradePrice xmlns :m="Some-URI"> 
<m: tickerSymbol>DIS</m: tickerSymbol> 
</m:GetLastTradePrice> 
</soapenv : Body> 
</soapenv : Envelope> 
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SOAP Message Embedded in HTTP Response 

HTTP/1.1 200 OK 

Content-Type: text/xml; charset="utf-8" 
Content-Length : nnnn 

<soapenv: Envelope xmlns : soapenv="http: //schemas .xmlsoap.org/soap/envelope/"> 

<soapenv: Body> 

<m:GetLastTradePriceResponse xmlns :m="Some-URI"> 

<m:price>34 .5</m:price> 
</m: GetLastTradePriceResponse> 
</soapenv : Body> 
</soapenv: Envelope> 



A 3. Location of Extensibility Elements 

Extensibility elements can appear at the following locations in a WSDL document: 



Location 



Meaning 



Possible usage 



The extensibility 
element applies 
to the WSDL 
document as a 
whole. 



• Introduce 
additional 



definitions 



information or 
definitions to a 
WSDL document 
as a whole. 



definitions/types 



The extensibility 
element is a 
type system. 



• Specify the format 
of the message in a 
type system other 
than XSD. 



definitions/service 



The extensibility 
element applies 
to the service. 



• Introduce 
additional 
information or 
definitions for the 
service. 



definitions/service/port 



The extensibility 
element applies 
to the port. 



* Specify an 
address for the 
port. 



The extensibility 
element applies 
to the binding as 
a whole. 



• Provide protocol 
specific information 



definitions/binding 



that applies to all 
the operations in 
the port type being 
bound. 
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definitions/binding/operation 



definitions/binding/operation/input 



definitions/binding/operation/output 



defmitions/binding/operation/fault 



The extensibility 
element applies 
to the operation 
as a whole. 



The extensibility 
element applies 
to the input 
message for the 
operation. 



The extensibility 
element applies 
to the output 
message of the 
operation. 



The extensibility 
element applies 
to a fault 
message of the 
operation. 



• Provide protocol 
specific information 
that applies to both 
the input message 
and the output 
message. 

• Provide details on 
how abstract 
message parts 
map into the 
concrete protocol 
and data formats of 
the binding. 

• Provide additional 
protocol specific 
infomiation for the 
input message. 

• Provide details on 
how abstract 
message parts 
map into the 
concrete protocol 
and data formats of 
the binding. 

' Provide additional 
protocol specific 
information for the 
output message. 

• Provide details on 
how abstract 
message parts 
map into the 
concrete protocol 
and data formats of 
the binding. 

• Provide additional 
protocol specific 
information for the 
fault message. 
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A 4. Schemas 

A 4.1 WSDL Schema 

<schema xmlns="http: //www. w3. org/2000/lO/XMLSchema" 

xinlns:wsdl="http: //schemas. xmlsoap.org/wsdl/" 
targetNamespace="http : //schemas . xmlsoap.org/wsdl/" 
element FormDefault="qualified"> 
<element name="documentation"> 
<complexType mixed="true"> 

<choice minOccurs="0" maxOccurs="unbounded"> 

<any minOccurs="0" maxOccurs="unbounded"/> 
</choice> 
<anyAttribute/> 
</complexType> 
</element> 

<complexType name="documented" abstract="true"> 
<sequence> 

<element ref="wsdl : documentation" minOccurs="0"/> 
</sequence> 

</complexType> 

<complexType name="openAtts" abstract="true"> 
<annotation> 

<documentation> 

This type is extended by component types 

to allow attributes from other namespaces to be added. 

</documentation> 

</annotation> 

<sequence> 

<element ref="wsdl : documentation" minOccurs="0"/> 
</sequence> 

<anyAt tribute namespace="##other"/> 
</complexType> 

<element name="def initions" type="wsdl :def initionsType"> 
<key name="message"> 

<selector xpath="message"/> 

<field xpath="@name"/> 
</key> 

<key name="portType"> 

<selector xpath="portType"/> 

<field xpath="@name"/> 
</key> 

<key name="binding"> 

<selector xpath="binding"/> 
<field xpath="@name"/> 

</key> 

<key name="service"> 

<selector xpath="service"/> 
<field xpath="@name"/> 
</key> 

<key name= " import "> 

<selector xpath=" import "/> 
<field xpath="@namespace"/> 
</key> 
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<key name="port"> 

<selector xpath="service/port"/> 

<field xpath="ename"/> 
</key> 

</element> 

<complexType name="def initionsType"> 
<complexContent> 

<extension base="wsdl : docuinented"> 
<sequence> 

<element ref="wsdl : import " minOccurs="0" maxOccurs=" unbounded "7 > 
<element ref="wsdl : types" minOccurs="0"/> 

<eleinent ref="wsdl :message" minOccurs="0" inaxOccurs="unbounded"/> 
<element ref ="wsdl :portType" ininOccurs="0" maxOccurs="unbounded"/> 
<element ref="wsdl :binding" minOccurs="0" maxOccurs="unbounded"/> 
<elenient ref ="wsdl : service" minOccurs="0" maxOccurs="unbounded"/> 
<any namespace="##other" minOccurs="0" maxOccurs="unbounded"> 
<annotation> 

<documentation>to support extensibility elements </documentatio 
</annotation> 
</any> 
</sequence> 

<attribute name="targetNamespace" type="uriRef erence" use="optional"/> 
ottribute name="name" type="NMTOKEN" use="optional"/> 
</extension> 
</complexContent> 
</complexType> 
<element name="import " type="wsdl : importType"/> 
<complexType name=" import Type "> 

<complexContent> 
<extension base="wsdl : documented"> 

<attribute name="namespace" type="uriReference" use="required"/> 
ottribute name="location" type="uriRef erence" use="required"/> 

</extension> 
</complexContent> 
</complexType> 

<element name="types" type="wsdl : typesType"/> 

<complexType name="typesType"> 
<complexContent> 

<extension base="wsdl : documented"> 

<sequence> 

<any namespace="##other" minOccurs="0" maxOccurs="unbounded"/> 
</sequence> 

</extension> 
</complexContent> 
</complexType> 
<element name="message" type="wsdl :messageType"> 
<unique name="part"> 

<selector xpath="part "/> 
<field xpath="@name"/> 
</unique> 
</element> 

<complexType name="messageType"> 

<complexContent> 
<extension base="wsdl :documented"> 
<sequence> 

<element ref ="wsdl : part" minOccurs="0" maxOccurs="unbounded"/> 
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</sequence> 

<attribute name="name" type="NCName" use="required"/> 
</extension> 
</complexContent> 
</complexType> 
<element name="part" type="wsdl :partType"/> 
<complexType name="partType"> 

<coinplexContent> 
<extension base="wsdl :openAtts"> 

<attribute name="nanie" type="NMTOKEN" use="optional"/> 
<attribute name="type" type="QNaine" use="optional"/> 
<attribute name="element" type="QName" use="optional"/> 

</extension> 
</complexContent> 
</coniplexType> 

<element name="portType" type="wsdl :portTypeType"/> 

<complexType name="portTypeType"> 
<coniplexContent> 

<extension base="wsdl :documented"> 

<sequence> 

<eleinent ref="wsdl : operation" minOccurs="0" inaxOccurs="unbounded"/> 
</sequence> 

<attribute naine="name" type="NCName" use="required"/> 
</extension> 
</complexContent> 
</complexType> 
<eiement name="operation" type="wsdl : operationType"/> 
<complexType naine="operationType"> 

<complexContent> 
<extension base="wsdl : documented"> 
<choice> 

<group ref ="wsdl : one-way-operation" /> 
<group ref="wsdl: request-response-operation"/> 
<group ref="wsdl: solicit-response-operation"/> 
<group ref="wsdl motif ication-operation"/> 

</choice> 

<attribute name="name" type="NCName" use="required"/> 
</extension> 
</complexContent> 
</complexType> 
<group name="one-way-operation"> 
<sequence> 

<element ref="wsdl: input "/> 
</sequence> 
</group> 

<group name- "request-response-operat ion" > 
<sequence> 

<element ref ="wsdl : input "/> 
<eleinent ref ="wsdl : output "/> 

<element ref ="wsdl : fault " minOccurs="0" maxOccurs="unbounded"/> 
</sequence> 
</group> 

<group name="solicit-response-operation"> 
<sequence> 

<element ref ="wsdl : output "/> 
<element ref="wsdl : input"/> 
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<element ref="wsdl : fault" minOccurs="0" maxOccurs="unbounded"/> 
</sequence> 
</group> 

<group name="notif ication-operation"> 

<sequence> 

<element ref="wsdl : output "/> 

</sequence> 
</group> 

<element name="input" type="wsdl:paramType"/> 
<eleinent name="output " type="wsdl :paramType"/> 
<eleinent name="fault" type="wsdl: faultType"/> 
<complexType name="paramType"> 

<complexContent> 
<extension base="wsdl : docuinented"> 

<attribute name="name" type="NMTOKEN" use="optional"/> 

ottribute name= "mess age" type="QName" use="required"/> 
</extension> 
</coinplexContent> 
</complexType> 
<complexType name="faultType"> 

<coinplexContent> 
<extension base="wsdl : documented"> 

<attribute name="name" type="NMTOKEN" use="required"/> 

<attribute nanie="niessage" type="QName" use="required"/> 

</extension> 
</coinplexContent> 
</complexType> 

<complexType nanie="startWithExtensionsType" abstract="true"> 

<complexContent> 
<extension base="wsdl : documented"> 
<sequence> 

<any namespace="##other" ininOccurs="0" maxOccurs="unbounded"/> 
</sequence> 

</extension> 
</coinplexContent> 
</complexType> 

<element name="binding" type="wsdl :bindingType"/> 

<complexType nanie="bindingType"> 
<coinplexContent> 

<extension base="wsdl : startWithExtensionsType"> 

<sequence> 

<element name="operation" type="wsdl :binding_operationType" minOccurs="0" maxOccu 
</sequence> 

<attribute name="name" type="NCName" use="required"/> 
<attribute name="type" type="QNanie" use="required"/> 
</extension> 
</complexContent> 
</complexType> 
<complexType name="binding_operationType"> 

<complexContent> 
<extension base="wsdl : startWithExtensionsType"> 
<sequence> 

<element name="input " type="wsdl : startWithExtensionsType" minOccurs="0"/> 

<element naine="output" type="wsdl : StartWithExtensionsType" minOccurs="0"/> 
<element name="f ault " minOccurs="0" maxOccurs="unbounded"> 
<complexType> 
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<complexContent> 

<extension base="wsdl : startWithExtensionsType"> 
<attribute name="name" type="NMTOKEN" use="required"/> 
</extension> 
</complexContent> 
</complexType> 
</element> 
</sequence> 

<attribute name-"name" type="NCName" use="required"/> 
</extension> 
</complexContent> 
</coinplexType> 
<element name="service" type="wsdl : serviceType"/> 
<complexType naine="serviceType"> 

<complexContent> 
<extension base="wsdl : documented"> 
<sequence> 

<element ref="wsdl :port " minOccurs="0" maxOccurs="unbounded"/> 
<any namespace="##other" niinOccurs="0"/> 
</sequence> 

<attribute name="name" type="NCNaine" use="required"/> 
</extension> 
</complexContent> 
</complexType> 

.<element name="port" type="wsdl :portType"/> 
<coinplexType naine="portType"> 

<complexContent> 
<extension base="wsdl :docuniented"> 

<sequence> 

<any nainespace="##other" minOccurs="0"/> 
</sequence> 

<attribute name="name" type="NCName" use="required"/> 
<attribute name="binding" type="QNanie" use="required"/> 
</extension> 

</complexContent> 

</complexType> 

<attribute name="arrayType" type="string"/> 
</schema> 

A 4.2 SOAP Binding Schema 

<schema xmlns="http: //www. w3 . org/2000/lO/XMLSchema" 

xmlns : soap="http: //schemas . xmlsoap. org /wsdl/ soap/" 
targetNamespace="http: //schemas . xmlsoap. org/wsdl/soap/"> 
<element name="binding" type="soap:bindingType"/> 
<complexType name="bindingType"> 

<attribute name="transport " type="uriRef erence" use="optional "/> 
<attribute naine="style" type="soap: styleChoice" use="optional"/> 
</complexType> 

<simpleType name="styleChoice"> 

<restriction base="string"> 
<enuineration value="rpc"/> 

<enuineration value="document "/> 
</restriction> 
</simpleType> 
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<eleinent name="operation" type="soap:operationType"/> 

<complexType name="operationType"> 

<attribute name="soapAction" type^"uriReference" use="optional"/> 
<attribute name="style" type="soap: styleChoice" use="optional"/> 

</complexType> 

<element naine="body" type="soap:bodyType"/> 

<complexType name="bodyType"> 

<attribute name="encodingStyle" type="uriRef erence" use="optional"/> 
<attribute name="parts" type="NMTOKENS" use="optional"/> 
<attribute naine="use" type="soap: useChoice" use="optional"/> 
<attribute name="namespace" type="uriRef erence" use="optional"/> 

</complexType> 

<simpleType name="useChoice"> 

<restriction base="string"> 
<enumeration value="literal"/> 

<enumeration value="encoded"/> 
</ restrict ion> 
</sinipleType> 

<eleinent naine-"f ault " type="soap: faultType"/> 
<complexType name="f aultType"> 

<complexContent> 
<restriction base="soap:bodyType"> 

<attribute name="parts" type="NMTOKENS" use="prohibited"/> 

</restriction> 
</complexContent> 
</coniplexType> 

<element name="header" type="soap:headerType"/> 

<compiexType name="headerType"> 
<all> 

<eleinent ref="soap:headerf ault"> 
</all> 

<attribute name="inessage" type="QNaine" use="required"/> 
<attribute naine="parts" type="NMTOKENS" use="required"/> 
<attribute naine="use" type="soap: useChoice" use="required"/> 
<attribute name="encodingStyle" type="uriRef erence" use="optional"/> 
<attribute name="namespace" type="uriRef erence" use="optional"/> 
</coinplexType> 

<element name="header fault" type="soap : headerf aultType"/> 

<complexType naine="header fault Type "> 

<attribute name="message" type="QName" use="required"/> 
<attribute name="parts" type="NMTOKENS" use="required"/> 
<attribute name="use" type="soap:useChoice" use="required"/> 
<attribute name="encodingStyle" type="uriRef erence" use="optional"/> 
<attribute name="namespace" type="uriRef erence" use="optional"/> 

</coinplexType> 

<element name="address" type="soap: addressType"/> 
<complexType name="addressType"> 

<attribute naine=" location" type="uriRef erence" use="required"/> 
</complexType> 
</schema> 



A 4.3 HTTP Binding Schema 

<schema xnilns="http: //www. w3 .org/2000/lO/XMLSchema" 
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xmlns : http="http : //schemas . xmlsoap . org/wsdl /http/ " 
targetNamespace="http : //schemas . xmlsoap . org/wsdl/http/ "> 

<element name="address" type="http: addressType"/> 

<complexType name="addressType"> 

<attribute name="location" type=^"uriRef erence" use="required"/> 

< / comp 1 e xT ype > 

<element name="binding" type-"http:bindingType"/> 
<complexType name="bindingType"> 

<attribute name="verb" type="NMTOKEN" use="required"/> 

</complexType> 

<element name="operation" type="http:operationType"/> 
<complexType name="operationType"> 

<attribute name="location" type="uriReference" use="required"/> 
</complexType> 
<element name="urlEncoded"> 

<complexType> 
</complexType> 
</element> 

<element name="urlReplacement "> 
<complexType> 
</complexType> 
</element> 
</ schema > 

A 4.4 MIME Binding Schema 

<schema targetNamespace="http : / /schemas . xmlsoap . org/wsdl /mime/ " 
xmlns :mime="http: //schemas . xmlsoap . org/wsdl/mime/" 
xmlns="http: //www.w3.org/2000/10/XMLSchema"> 
<element name="content " type="mime : contentType"/> 
<complexType name="contentType" content="empty"> 

<attribute name="type" type="string" use="optional"/> 
<attribute name="part" type="NMTOKEN" use="optional"/> 
</complexType> 

<element name="multipartRelated" type="mime :multipartRelatedType"/> 
<complexType name="multipartRelatedType" content="elementOnly"> 

<element ref="mime:part" minOccurs="0" maxOccurs="unbounded"/> 
</complexType> 

<element name="part" type="mime :partType"/> 

<complexType name="partType" content="elementOnly"> 

<any namespace="targetNamespace" minOccurs="0" maxOccurs=="unbounded"/> 
<attribute name="name" type="NMTOKEN" use="required"/> 

</complexType> 

<element name="mimeXml" type='*mime :mimeXmlType"/> 
<complexType name="mimeXmlType" content="empty"> 

<attribute name="part" type="NMTOKEN" use="optional"/> 
</complexType> 
</schema> 
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